The invention relates generally to computer systems, and more particularly to computer applications for returning information to browsers in response to user requests.
Early Internet servers were able to process client requests only by receiving a URL (uniform resource locator) sent by a client, accessing a database or file system based on that URL, and returning information corresponding thereto to the client. Such a simple lookup operation provides an essentially a static client-server model, as the server simply receives a location via the URL and returns data stored at that location to the client.
An improvement to the above-described static client-sever model involves the use of a CGI (common gateway interface) script. CGI is a protocol used for communicating between client data and a program on the server side. With CGI, the client typically sends form data along with a program location to the server. Instead of simply returning static data to the user, the server runs the identified program to initially generate some results, and thereafter return the dynamically-generated results as an HTML (Hypertext Markup Language) page. With CGI, the executing program can operate on the input data as desired by the developer, potentially communicating with other servers to generate the results.
By way of example, a client sends a name (e.g., text) as data to a server, along with program information identifying a program for operating on that name data. The server executes the identified program, which (in this example) uses the data to access a stock portfolio associated with the name, possibly by communicating with another server. The executing program further obtains the current prices of the stocks in the portfolio, (again possibly via another server), and uses the portfolio and price information to generate a summary table, in the form of an HTML page, of the named individual""s stock holdings. The server then returns the summary table to the client, which the client browser interprets to output a graphical display corresponding thereto. As can be appreciated, the use of CGI script provides a dynamic client-server model, since the result depends on the data sent by the user and the operation of a program on that data.
However, CGI is a rather heavyweight (and therefore expensive) mechanism in that an entire program is loaded and run in response to each CGI request. As a result, a more lightweight mechanism has been developed that uses dynamic link libraries (DLLs) instead of fully executable programs. A DLL is a library of small functions, each of which can be separately (and quickly) linked at run-time to an already-executing process in the server. The use of DLLs can be highly flexible. For example, a server process can selectively maintain in memory any currently-loaded DLLs, thereby avoiding reloading operations for use with other client requests. Long-unused DLLs can be removed from memory to free up space, while still others can be preloaded into memory in anticipation of servicing client requests therewith.
One such lightweight, DLL-based mechanism for processing client requests is Microsoft Corporation""s Internet Server Application Programming Interface (ISAPI) for Microsoft Internet Information Server (IIS). ISAPI provides the dynamic aspect of CGI, but with the efficiency gains realized by DLLs. ISAPI DLLs are also called ISAPI applications and/or ISAPI extensions. ISAPI thus provides application developers with an excellent tool for developing efficient server extensions.
However, ISAPI (and other server-side) extensions are significantly and architecturally different from programs written for client-side applications. For example, to return results to a client, server extensions ordinarily construct and transfer a complete HTML page, often including text, images and other information, to a client-side browser. In contrast, local, client-side applications may use some similar code to obtain the results, but then use WIN32 APIs to output those results as graphical data to a user interface written for that application.
Because of these differing architectures, little, if any code can be shared between extensions written for remote servers and applications written for local client machines. Rather than expend resources to develop programs for both architectures, product developers generally choose to develop and market their products either for remote servers (accompanied with an appropriate a server extension) or a local client application, but not both. For example, a developer of a multimedia encyclopedia product on CD-ROM will determine the intended market, and then either write a server extension or a client application for accessing the multimedia data therein. Consequently, someone wishing to use a server-directed encyclopedia product is required to connect as a client to an appropriately-equipped server.
Accordingly, it is a general objective of the present invention to provide a method and mechanism for handling on the client side, extensions written for a server.
Another objective is to provide a method and mechanism of the above kind that enables developers to write a single extension for use with either server or client machines.
In accomplishing those objectives, another objective is to provide a local client application that uses an existing web browser as a user interface.
A related objective is to provide the method and mechanism as characterized above without requiring any significant modifications to the web browser.
Another objective is to accomplish the above objectives while providing a highly efficient, flexible and extensible method and mechanism.
Briefly, the present invention provides a method and mechanism for executing an extension (e.g., ISAPI application) in a local machine. A browser is loaded in the local machine, and is provided with information indicating that the extension is present locally. The browser recognizes the local presence of the extension, and selects and/or creates a moniker object for interfacing between the browser and the extension. The moniker object includes data and code for loading the extension in the local machine and for passing data between the browser and the extension. When the extension processes data received from the browser to produce a result, the result is returned (such as in an HTML document) from the extension to the browser via the interface. The browser displays the result in its intended form, i.e., a graphical, human-readable format.
Other objects and advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which: